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Claims 1-5, 7, 9, 11, 12, 14-16, and 18-25 are currently pending in this 
application. Claims 1, 2, 4, 5, 7-9, 11-14, 16, and 18-25 stand rejected under 35 
U.S.C. §112 as failing to comply with the written description requirement. Claims 
1, 2, 4, 5, 7-9, 11-14, 16, and 18-25 stand rejected under 35 U.S.C. §102(e) as 
being anticipated by U.S. Patent Application Publication No. 2003/0158836 to 
Venkatesh et al. (hereinafter " Venkatesh "). Claims 1, 2, 4, 5, 7-9, 11-14, 16, and 
18-25 stand rejected under 35 U.S.C. §112 as failing to comply with the written 
description requirement. The Examiner asserts this rejection by reciting that 
"[t]he Specification does not include "before the IRP reaches a file system 
associated with the IRP." See Office Action in If 3 at p. 2. 

The Applicant respectfully points the Examiner to the following paragraph 
on p. 7 of the Specification: 

It is important to note that the volume filter preferably is 
software written specifically to implement the present invention 
i.e., logically combine Basic Volumes, referred to as extents, so 
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that any number of Basic Volumes possibly located on separate 
disks may appear and be presented to users as a single Data 
Volume, as explained herein. As mentioned, the volume filter is 
conceptually above the Basic Volumes so that IRPs are 
processed by the volume filter prior to being processed by the 
Basic Volume Manager . The volume filter is incorporated into the 
operating system and only the I/O manager is aware that it is 
there. That is, I/O originators think they are talking to a single 
Basic Volume and are not aware that their I/O may be redirected 
according to the logic of a particular Data Volume. 
(Emphasis Added). 

The Applicants maintain that processing the IRP BEFORE REACHING A 
FILE SYSTEM to be described when the IRP is processed PRIOR to being 
processed by the Basic Volume Manager. As such, withdrawal of the rejection is 
requested. If the Examiner does not agree with this interpretation by the 
Applicants, the Applicants invite the Examiner to contact the undersigned 
attorney for the Applicants to determine claim language that the Examiner 
believes is acceptable to the Examiner. 

Claims 1, 2, 4, 5, 7-9, 11-14, 16, and 18-25 stand rejected under 35 
U.S.C. §1 02(e) as being anticipated by U.S. Patent Application Publication No. 
2003/0158836 to Venkatesh et al. (hereinafter " Venkatesh "). Claim 1, which is 
representative of the independent claims 9, 14, and 23, recites intercepting an 
initial IRP before the IRP reaches a file system associated with the IRP and 
implementing the method above a Basic Volume Manager. 

The Examiner interprets the "volume filter" of claim 1 as a "data mover" in 
Venkatesh . Applicants respectfully disagree for the following reasons. To 
intercept an IRP before it is received by an associated file system and to 
implement the volume filter above a Basic Volume Manager, the volume filter 
would need to be implemented outside of the native operating system. For 
example, the volume filter could be implemented as a driver and would need to 
communicate to the operating system through some mechanism like an I/O 
manager. 
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Venkatesh's data movers are computers (paragraph 0054; "Each of the 
data movers 115, 116, 117 is a high-end commodity computer") implemented as 
part of a distributed network's file server (paragraph 0010, Figure 9). The claimed 
volume filters are distinguishable from the data movers of Venkatesh , in that a 
high-end commodity computer could not be implemented above a Basic Volume 
Manager, nor could it intercept an input/output request packet before it is 
received by the associated file system. Figure 9 illustrates that the file system 
(144) is part of the data mover (115). The data mover cannot act independently 
of the file system in Figure 9, and therefore cannot perform the functions of the 
claimed volume filters. Even if it were interpreted that software implemented and 
replicated on each data mover computer of Venkatesh was equivalent to the 
claimed volume filter, Venkatesh recites that a request is forwarded to the data 
mover from the meta file system manager. 

Software implemented in Venkatesh's data movers does not intercept 

IRPs before they are received by the associated file system. Venkatesh 

describes three file systems, and their respective relation to the meta file system 

manager. In paragraph 0061, describing the network file system (NFS), a client 

makes a request for access to a file. 

"A client first issues an NFS lookup request including a path 
to a file and the filename for the file to be accessed. The lookup 
request returns a file handle for a file entry corresponding to the file. 
The client uses the file handle in subsequent requests for access to 
the file. These subsequent request are interpreted by the NFS 
routines 141 and forwarded to the meta file system manager 146." 
(emphasis added). 

Clearly, the NFS accesses the request before the meta file system 
manager. Paragraph 0062 describes the operation under the Common Internet 
File System (CIFS). "The CIFS server routines 142 receive the CIFS request 
from the client and forward the request through the Virtual File System (VFS) to 
the meta file system manager 146." Again, the CIFS accesses the request before 
the meta file system manager and the VFS. A similar scenario describing the 
UNIX file system (UxFS) is described in paragraph 0074. 
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Venkatesh does not disclose a volume filter as claimed. Venkatesh does 
not disclose intercepting an input/output request packet before it reaches the 
associated file system. Venkatesh does not disclose implementing a meta file 
system above a Basic Volume Manager as claimed. Therefore, claim 1 is 
patentable over Venkatesh for the reasons presented above. 

The Applicants made these arguments in the prior Amendment in 

response to an Office Action. In the Action dated September 29, 2008, the 
Examiner restates these same rejections and then fails to respond to the 
Applicants' arguments in any way. The Applicants do not understand how the 
Examiner expects them to respond to these rejections when the Examiner has 
not stated anything more than what was stated before. In the MPEP § 706.07, 
the Examiner is instructed as follows: 

Before final rejection is in order a clear issue should be 
developed between the examiner and applicant. To bring the 
prosecution to as speedy conclusion as possible and at the same 
time to deal justly by both the applicant and the public, the invention 
as disclosed and claimed should be thoroughly searched in the first 
action and the references fully applied; and in reply to this action 
the applicant should amend with a view to avoiding all the grounds 
of rejection and objection. Switching from one subject matter to 
another in the claims presented by applicant in successive 
amendments, or from one set of references to another by the 
examiner in rejecting in successive actions claims of substantially 
the same subject matter, will alike tend to defeat attaining the goal 
of reaching a clearly defined issue for an early termination, i.e., 
either an allowance of the application or a final rejection. 

While the rules no longer give to an applicant the right to 
"amend as often as the examiner presents new references or 
reasons for rejection," present practice does not sanction hasty and 
ill-considered final rejections. The applicant who is seeking to 
define his or her invention in claims that will give him or her the 
patent protection to which he or she is justly entitled should receive 
the cooperation of the examiner to that end, and not be prematurely 
cut off in the prosecution of his or her application. But the applicant 
who dallies in the prosecution of his or her application, resorting to 
technical or other obvious subterfuges in order to keep the 
application pending before the primary examiner, can no longer find 
a refuge in the rules to ward off a final rejection. 
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The examiner should never lose sight of the fact that in 
every case the applicant is entitled to a full and fair hearing, and 
that a clear issue between applicant and examiner should be 
developed, if possible, before appeal. However, it is to the interest 
of the applicants as a class as well as to that of the public that 
prosecution of an application be confined to as few actions as is 
consistent with a thorough consideration of its merits. 

Neither the statutes nor the Rules of Practice confer 
any right on an applicant to an extended prosecution; Ex parte 
Hoogendam, 1939 CD. 3, 499 O.G.3, 40 USPQ 389 (Comm'r Pat. 
1939). 

STATEMENT OF GROUNDS 

In making the final rejection, all outstanding grounds of 
rejection of record should be carefully reviewed, and any such 
grounds relied on in the final rejection should be reiterated. They 
must also be clearly developed to such an extent that applicant 
may readily judge the advisability of an appeal unless a single 
previous Office action contains a complete statement supporting 
the rejection. 

However, where a single previous Office action contains a 
complete statement of a ground of rejection, the final rejection may 
refer to such a statement and also should include a rebuttal of 
any arguments raised in the applicant's reply. If appeal is taken in 
such a case, the examiner's answer should contain a complete 
statement of the examiner's position. The final rejection letter 
should conclude with Form Paragraph 7,39. 
(Emphasis added). 

The Applicants respectfully request that the Examiner provide a proper 
response to the Applicants' arguments to permit Applicants to respond in a 
matter that either moves the issues forward and/or properly frames the issue for 
an appeal. 



Conclusion 

Claims 1-5, 7, 9, 11, 12, 14-16, and 18-25 are currently pending in this 
application. Applicants have on more than one occasion now made arguments 
with respect to the pending rejection of this case in which the Examiner has failed 
to adequately respond. 
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For example, the rejection under 35 U.S.C. 112 rejecting "intercepting an 
initial IPR before the IRP reaches a file system" by quoting the Specification (as 
is done above) how an IRP is intercepted and "processed by the volume filter 
prior to being processed by the Basic Volume Manager." In spite of this quote, 
the Examiner continues to assert that the limitation does not "include before the 
IRP reaches a file system." Additionally, the examiner asserts that the 
"[sjpecification does not disclose a file system." Because the invention relates to 
creating Data Volumes for storage of data above basic storage volumes such as 
are implemented within a Microsoft Windows operating system (see Specification 
at pp. 6-7 for example), the Applicants have no way to respond to this argument. 
Simply stated the Examiner is both factually and logically wrong. 

Similar arguments with respect to the characterization and application of 
the prior art are made as noted above. The Examiner has failed to respond to 
Applicants' arguments in multiple rejections. 

Applicant respectfully requests this panel to reconsider and issue the 
subject application. If any issues remain that preclude issuance of this 
application, the Examiner is again urged to contact the undersigned attorney. 

Respectfully submitted, 
Chimitt et al. 

Dated: November 9, 2009 By : /Richard J. Greqson/ 

Richard J. Gregson 
Registration No. 41,804 
Attorney for Applicants 
Unisys Corporation 
Unisys Way, MS/S1-108 
Blue Bell. PA 19424 
(215) 986-3325 
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